home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / ODF's Color Model < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  4.7 KB  |  [TEXT/ttxt]
  1. Subject:     ODF's Color Model
  2. Sent:        5/23/96 8:54 PM
  3. Received:    5/24/96 8:49 AM
  4. From:        Martin Sandberg, msandber@Sigma4.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8.   While working on a 3-d icon for ODF, I ran into a problem with the color
  9. handling in ODF, specifically with FW_SColor (in <SLColor.h> of DR5).  The
  10. internal representation is (by inference & reverse engineering, the
  11. documentation is unhelpful on this issue) as a single long, with the red, green
  12. and blue intensitites encoded as bytes from least toward most significant.
  13.  
  14.    However, there is a hole in the following snip from SLColor.h:
  15.  
  16. struct  FW_SColor
  17. {
  18.         unsigned long   fRGB;
  19. };
  20.  
  21. #define FW_RGB(r, g, b) (((unsigned long)(r)) | ((unsigned long)(g) << 8) |
  22. ((unsigned long)(b) << 16))
  23.  
  24. inline void FW_SetRGB(FW_SColor& color, short r, short g, short b)
  25. {
  26.         color.fRGB = FW_RGB(r, g, b);
  27. }
  28.  
  29. inline unsigned char FW_RGB_R(FW_SColor color)
  30. {
  31.         return (unsigned char) (color.fRGB);
  32. }
  33.  
  34. inline unsigned char FW_RGB_G(FW_SColor color)
  35. {
  36.         return (unsigned char) (color.fRGB >> 8);
  37. }
  38.  
  39. inline unsigned char FW_RGB_B(FW_SColor color)
  40. {
  41.         return (unsigned char) (color.fRGB >> 16);
  42. }
  43.  
  44.    The inlines FW_RGB_R, ...G, and ...B clearly show an intent to encode
  45. the RGB values as 8-bit (uchar) intensities.  Unfortunately, the setting inline
  46. function FW_SetRGB uses the value-setting macro FW_RGB with short values
  47. for r, g, and b.  If one looks at the Set function's interface, which is
  48. reflected upward to _all_ color classes and their interfaces, one is lead to
  49. believe that 16-bit (i.e., Mac-like) color values are supported.  This is not
  50. the case, unfortunately.  Although the parameters are shorts, only values in
  51. the range 0..255 will work _correctly_.  All others _will_ result in incorrect
  52. colors being encoded in the ulong fRGB.
  53.   It sure would have been nice to see a proper interface, using unsigned char's
  54. as the parameters, for setting rgb values.  This would have been clear and
  55. unambiguous and _correct_ in every sense.  The current system is none of those
  56. desirable characteristics.  But this would only mask a deeper problem with
  57. ODF's color model.
  58.    I consider the basic ODF color representation (a single unsigned long
  59. _encodoing_  of an 8-bit rgb color model) to be inadequate.  For example, SGI
  60. is now shipping a (medical imaging) system using triple 12-bit DAC's, requiring
  61. at least 36-bit representations of colors.  Then there is the Pantone Corp.'s
  62. Hexachrome (tm) hi-fi color system, with 6 color intensities.  How do we encode
  63. this system in 32 bits?  Hmmm?  5-bit intensities?
  64.    We need to fix this color model problem _now_, before so much code is
  65. written on the existing model that resistance to change becomes insurmountable.
  66. If ODF intends to provide a platform-independent imaging model, it cannot and
  67. must not rely upon a lowest-common-denominator approach, it must support a
  68. model that is powerful enough to support the most powerful existing models and
  69. allow for future growth in imaging technology.  I believe that this requires,
  70. among other things, a 48-bit or greater color model.
  71.  
  72.    While I'm in rant mode, I'd like to take a shot at the available ODF
  73. documentation.  Sure, ODF is a work in progress, but is that any excuse not to
  74. write meaningful comments in the code?  Remember, ODF source code must be
  75. read and understood by (hopefully tens of) thousands of programmers.  Getting
  76. all these people enthusiastic about ODF requires that we not have to work _too_
  77. hard to understand it.  The ODF Class Reference (ODFCR) is only about 2/3
  78. written, and even that is (necessarily, I realize) not fully up to date.  How
  79. am I supposed grok the essence (let alone the fullness) of anything in the
  80. framework layer when there is _no_ data in the ODFCR (at least the useable one
  81. in Quickview form) on the Framework layer?  I frankly don't have the spare time
  82. to waste thrashing thru the engineering notes, the development notes and other
  83. random possible sources to try to find prose explanations for why some things
  84. are done the way they are.  If such explanations exist except inside some
  85. already overworked Apple programmer's head.
  86.    I guess my complaint is that while ODF may grow into a really useful way to
  87. do OpenDoc parts, it will be a hard sell to the programmer community unless it
  88. is easier to use and understand.  That means (shudder <G>) documentation.
  89.    Otherwise, the Direct to SOM folks will win the "hearts and minds" battle,
  90. justifiably.
  91.  
  92.   ODF has a lot of potential, but it is a tool and the usability of any complex
  93. tool is highly dependant on its documentation.  Consider this a plea for some
  94. additional efforts in that area.
  95.  
  96. Martin, Bill & the Sigma 4 gang
  97.  
  98.